Skip to content

docs(node): confirm v6.6 SC migration model, add version-scoping note for operators - #39

Merged
alexander-sei merged 3 commits into
docs/skills-registry-and-templatesfrom
docs/giga-sc-modes-v652
Aug 8, 2026
Merged

docs(node): confirm v6.6 SC migration model, add version-scoping note for operators#39
alexander-sei merged 3 commits into
docs/skills-registry-and-templatesfrom
docs/giga-sc-modes-v652

Conversation

@alexander-sei

@alexander-sei alexander-sei commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

Context

A review finding on the SC config docs claimed the [state-commit] model on the skills-registry branch (memiavl_only migration enum + sc-keys-to-migrate-per-block) described "unreleased main". That finding is outdated as of this morning: v6.6.0-rc1 (tagged 2026-07-02) ships exactly this model, so the branch text is correct for v6.6 and stays.

Verified against sei-chain tags v6.5.2, v6.6.0-rc1, and main @ 9f53204:

v6.5.x (stable) v6.6.0-rc1 main (post-#3650)
sc-write-mode cosmos_only / dual_write / split_write memiavl_onlymigrate_evm → … → flatkv_only same enum + auto
sc-read-mode / sc-enable-lattice-hash exist removed removed
drain rate n/a sc-keys-to-migrate-per-block (app.toml, default 1024) NumKeysToMigratePerBlock gov param (default 0)
mode selection manual manual sc-write-mode-enable-auto = true derives it, ignores explicit key

Changes (on top of the skills-registry branch)

  • Version-scoping <Note> in the Giga Storage section: the SC keys documented here are v6.6+; v6.5.x uses the old key set, and each binary line rejects the other's sc-write-mode values at startup (no compat mapping in app/seidb.goParseWriteMode panics), so operators must update app.toml when crossing v6.6. The removed sc-read-mode/sc-enable-lattice-hash keys are merely ignored. Also flags the post-v6.6 gov-driven rework already on main.
  • Auto-generated app.toml block: mirror the exact v6.6.0-rc1 template comment for sc-keys-to-migrate-per-block (drain-rate tuning guidance) and drop the extra "defaults to memiavl_only" line so the block matches real seid init output.

🤖 Generated with Claude Code

@cursor

cursor Bot commented Jul 2, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Documentation-only edits to node operator guidance; no runtime or config code changes.

Overview
Operator docs now scope [state-commit] to the v6.6+ model and spell out what changes when crossing binary lines: v6.5.x sc-write-mode / sc-read-mode / sc-enable-lattice-hash vs v6.6 migration enums, startup rejection of mismatched mode values (with cosmos_onlymemiavl_only as the safe default path), and a heads-up that post-v6.6 main shifts drain rate to governance and adds sc-write-mode-enable-auto.

The auto-generated app.toml snippet for sc-keys-to-migrate-per-block is updated to match v6.6.0-rc1 template text (production vs test tuning) and drops the redundant “defaults to memiavl_only” line on sc-write-mode.

Reviewed by Cursor Bugbot for commit 35f0b30. Bugbot is set up for automated code reviews on this repo. Configure here.

… note

The SC migration model on the skills-registry branch (memiavl_only
enum + sc-keys-to-migrate-per-block) is confirmed correct against the
v6.6.0-rc1 tag — the earlier review finding calling it 'unreleased main'
predated the rc cut and checked only v6.5.x tags and main.

Changes on top of the base branch:
- Mirror the exact v6.6.0-rc1 toml template comment for
  sc-keys-to-migrate-per-block in the auto-generated app.toml block
  (drain-rate tuning guidance; 'defaults to memiavl_only' line removed
  to match seid init output).
- Add a <Note> scoping the SC keys per version: v6.5.x uses
  cosmos_only/dual_write/split_write + sc-read-mode +
  sc-enable-lattice-hash, and each binary line rejects the other's
  sc-write-mode values at startup (no compat mapping in app/seidb.go),
  so operators must update app.toml when crossing v6.6. Also flags the
  post-v6.6 rework already on main (#3650): drain rate becomes the
  NumKeysToMigratePerBlock gov param and sc-write-mode-enable-auto
  (default true) derives the mode automatically.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@alexander-sei
alexander-sei force-pushed the docs/giga-sc-modes-v652 branch from e8995ff to 913efa6 Compare July 2, 2026 17:40
@alexander-sei alexander-sei changed the title fix(node): restore released v6.5.x SC config model, label FlatKV migration scheme as unreleased docs(node): confirm v6.6 SC migration model, add version-scoping note for operators Jul 2, 2026
alexander-sei and others added 2 commits August 7, 2026 18:05
v6.6.0 added a back-compat shim after v6.6.0-rc1 (which this page was
originally verified against): ParseSCWriteMode maps the legacy
"cosmos_only" to memiavl_only, so a v6.6.x binary accepts the v6.5
default rather than rejecting it. Only dual_write / split_write /
evm_only are rejected at startup.

Replaces the blanket "each binary rejects the other line's values"
claim with the asymmetric behavior, and narrows the upgrade
instruction accordingly -- operators on the v6.5 default need no
app.toml change. Also drops the now-stale "first tagged in v6.6.0-rc1"
parenthetical.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@alexander-sei
alexander-sei merged commit 8e3ce2e into docs/skills-registry-and-templates Aug 8, 2026
10 checks passed
@alexander-sei
alexander-sei deleted the docs/giga-sc-modes-v652 branch August 8, 2026 00:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant